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(54) Abstract Title: Converting between different versions of a standard at an interface between a network 
management centre and a network element manager 

(57) A method, and apparatus for, mediating between a telecommunications network management centre 
(NMC) (10) and a telecommunications network element manager (NEM) (4) over an interface (15) defined 
by a standard, the NMC (10) using a first version of the standard and the NEM (4) using a second version 
of the standard. For example, this may be used for different versions of the north bound interface (NBI) of 
the Universal Mobile Telecommunications System (UMTS) Management standard. A mediator (21) is 
provided that converts a request received from e.g. an Integration Reference Point (IRP) manager (23) of 
an NMC (10) under the first version of the standard to a corresponding request under the second version 
of the standard which it sends to e.g. an IRP agent (27) of an NEM (4); receives back a response under the 
second version of the standard; converts the response to a corresponding response under the first 
version of the standard; and sends the converted response under the first version of the standard to the 
IRP manager (23). 
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TELECOMMUNICATIONS NETWORK MANAGEMENT 
Field of the Invention 

The present invention relates to managing elements in a communications 
5 system. The present invention relates in particular, but not exclusively, to 
operations, administration, maintenance and provisioning in a national 
telecommunications network including cellular communications systems, the 
cellular communications systems including for example Universal Mobile 
Telecommunications System (UMTS), General Packet Radio Service (GPRS) and 
10 Global System for Mobile Telecommunication (GSM) systems. 

Background of the Invention 

The component parts of communications systems and networks may be 
15 divided into " communication elements' 7 and "management parts". The 
communication elements includes those parts whose basic function is 
implementing communication between parties in the system. In the case of 
cellular communications systems for example, these include base stations and 
switching centres (Node-B's and Radio Network Controllers (RNCs) respectively 
20 in the case of UMTS systems). 

The management parts include those parts whose basic function is to 
manage and support the operation of the communication elements of a network 
or system. In the case of cellular communications systems, for example, these 
25 include Operations and Management Centres (OMCs), also known as 



Operations, Administration and Maintenance (OA&M) or Operations, 
Administration, Maintenance and Provisioning (OAM&P). These contain 
databanks and instructions for managing operation of communications parts, e.g. 
a management part for a base station may include instructions for which radio 
frequencies the base station should transmit and receive on, data relating to 
handover, and so on. 

The management parts may be located in separate locations to the 
communications parts, or may be co-located therewith, the division comprising a 
functional division rather than a strict geographical division. 

In some communications systems or networks, the management parts are 
implemented in two or more hierarchical levels. This is the case for those systems 
which include UMTS and/or GPRS elements. For these, the OAM&P is 
implemented at two levels defined in the Third Generation Partnership Project 
(3GPP) Technical Specifications (i.e. 3rd Generation Partnership Project; 
Technical Specification Group Services and System Aspects; 3G Telecom 
Management: Principles and high level requirements (Release 5)). 

The higher level comprises Network Management Centres (NMCs) and 
the lower level comprises Network Element Managers (NEMs). The NEMs 
manage one or more specific elements of the network (i.e. one or more 
communications elements when put in the terminology used above), whereas the 
NMCs manage aspects related to an overall system or network, or at any least a 
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more substantial number of communications elements than are managed by the 
NEMs. 

The NMCs share an interface with the NEMs. This is referred to as the 
5 North Bound Interface (NBI), and is also defined in the above mentioned 3GPP 
Technical Specification. This enables multi-vendor NEMs to be managed by 
NMCs developed by various Independent Software Vendors (ISVs). 
Conceptually the NBI standard is modelled and specified by reference to the NBI 
with an Integration Reference Point (IRP) Manager responsible for implementing 
10 the so-called "north" requirements in the NMC (i.e. transmission from the NMC 
to the NEM, which direction is termed north in this interface) and an IRP Agent 
responsible for implementing the so-called "south" requirements in the NEM (i.e. 
transmission from the NEM to the NMC, which direction is termed south in this 
interface). 

15 

Due the way the standardization processes for technical standards such as 
the above mentioned 3GPP Technical Specification proceeds, the scope of the 
NBI is expanded as updated versions of the 3GPP Technical Specification are 
agreed and issued. For 3GPP this is done on a release basis, e.g. R99, R4 and R5. 

20 

This poses a problem when trying to deploy new versions of the NBI and 
for vendors and ISVs being able to support forward and backward compatibility. 
Ideally, to support rollout of release keeping the network operational all IRP 
Manager and IRP Agents instances would be able to support all valid versions. 
25 However, this is not achievable in practice. Vendors and ISVs may only be able 
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to support a subset of versions, for example a new vendor included in a network 
may only support the latest version, or an NMC supporting legacy features 
would not be maintained or required to support newer releases. 

5 If IRP Managers and IRP Agents support different versions there may be 

incompatibilities at various levels. For example:- 

1) Behaviour 

2) New/changed Operations 

3) New/changed Operations parameters 

10 4) New/changed Managed Object Classes (MOC) 
5) New/changed MOC attributes. 

Summary of the Invention 

15 In a first aspect, the present invention provides a method of 

communicating between a telecommunications network management centre and 
a telecommunications network element manager, as claimed in claim 1. 

In a further aspect, the present invention provides a method of mediating 
20 communication between a telecommunications network management centre and 
a telecommunications network element manager, as claimed in claim 2. 

In a further aspect, the present invention provides a storage medium 
storing processor-implementable instructions, as claimed in claim 9. 

25 
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In a further aspect, the present invention provides apparatus for 
mediating communication between a telecommunications network management 
centre and a telecommunications network element manager, as claimed in claim 
10. 

5 

In further aspects, the present invention provides a system and method 
for alleviating or resolving NBI (or equivalent interfaces) version 
incompatibilities between network managers and network element managers by 
means of mediation. 

10 

The present invention tends to alleviate or resolve incompatibilities across 
two versions of the interface when there are differences and it is required to 
support forward and backward incompatibilities in the network, e.g. over the 
NBI. For example, the following issues may be mediated:- 
15 1) Behaviour 

2) New/changed Operations 

3) New/changed Operations parameters 

4) New/changed Managed Object Classes (MOC) 

5) New/changed MOC attributes. 

20 

The present invention tends to allow network and system operators to 
simply rollout new NBI versions in live networks, and to support backward and 
forward compatibility across different vendor's NEM and ISVs NMC 
applications. 

25 



-6- 



Brief Description of the Drawings 

Embodiments of the present invention will now be described, by way of 
5 example only, with reference to the accompanying drawings, in which: 

FIG. 1 is a schematic illustration of a communications network; 

FIG. 2 is a schematic illustration showing a North Bound Interface (NBI) 
10 established between a network management centre and a network element 
manager; 

FIG. 3 is a schematic illustration showing an arrangement in which an NBI 
Version Mediator is arranged to provide enhanced compatibility between IRP 
15 Managers and IRP Agents over an NBI; 

FIG. 4 is schematic illustration of the NBI Version Mediator of FIG. 3 in 
terms of functional modules; 

20 FIG. 5 is a schematic illustration representing a request being sent by a 

client to an object implementation; 

FIG. 6 is a schematic illustration of a managed object containment tree, 
with IRP Agents scope superimposed over them; 

25 
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FIG. 7 is a call sequence flowchart showing process steps employed at a 
network level in an embodiment of the present invention; 

FIG. 8 is a call sequence flowchart showing process steps employed 
5 internally by the NBI Version Mediator of FIGs. 3 and 4 during an initialisation 
stage of the process shown in FIG. 7; and 

FIG. 9 is a call sequence flowchart showing process steps employed 
internally by the NBI Version Mediator of FIGs. 3 and 4 during an operation 
1 0 stage of the process shown in FIG. 7. 

Description of Preferred Embodiments 

FIG. 1 is a schematic illustration of a communications network 1 showing 
1 5 certain management components thereof. The network comprises cellular 

communications systems including UMTS and GPRS systems. These systems 
and other parts of the network comprise network elements (i.e. communication 
elements) such as base stations, switching centres (e.g. Node-B's and RNCs ), and 
Internet Protocol (IP) nodes. For clarity, the network elements are not shown in 
20 FIG. 1. 

The management components shown in FIG. 1 are arranged to manage the 
above described network elements. In this embodiment the management 
components comprise network element managers (NEMs) 2, 3, 4, 5, 6, 7 and 
25 network management centres (NMCs) 10, 11, 12 as specified in the 3GPP 
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Technical Specification. The NEMs and NMCs are interconnected as shown in 
FIG. 1. The NEMs 2, 3, 4, 5, 6, 7 are also each coupled to one or more respective 
network elements. 

5 Communication between the NMCs and the NEMs is performed over the 

above described North Bound Interface (NBI). For example, FIG. 2 is a schematic 
illustration showing an NBI 15 established between NMC 10 and NEM 4. Also 
shown in FIG. 2 is a connection between the NEM 4 and a network element (NE) 
16 it is arranged to manage. The NMC 10 comprises an application called an 
10 Integration Reference Point (IRP) Manager 17. The NEM 4 comprises an 
application called an IRP Agent 18. 

Different release versions of IRP Managers and IRP Agents may be 
present in a given network as standards and commercial requirements are 

1 5 modified. Also, different instances of IRP Managers and IRP Agents may be 
present, as different vendors or service providers build their own versions of 
these items. In this embodiment, an NBI version mediator is provided to give 
enhanced compatibility between different versions and instances of IRP 
Managers and IRP agents. (The term ''instances' 7 is used to refer to variations or 

20 replications of e.g. an Agent or a Manager which are substantially equivalent but 
may contain certain variations or differences. For example, different instances of 
an Agent may be generally intended to perform the same role to a same 
standard, but may be designed and implemented by two different vendors, and 
hence may show certain variations in how they operate or respond, perhaps in 

25 some detailed areas.) 
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FIG. 3 is a schematic illustration showing an NBI Version Mediator 21 
arranged to provide enhanced compatibility between IRP Managers 23, 24, 25 
and IRP Agents 26, 27, 28 over an NBI 29. FIG. 3 is a simplified idealised 
5 illustration representing an overview of how the NBI Version Mediator may be 
used to provide compatible interaction between the different versions of IRP 
Managers and IRP Agents. IRP Manager 23 is, say, a version "x"; IRP Manager 24 
is, say, a version "x-1"; and IRP Manager 25 is, say, a version "x+1". Similarly, 
IRP Agent 26 is, say, a version "x"; IRP Agent 27 is, say, a version "x-1"; and IRP 
10 Agent 28 is, say, a version "x+1". 

In this example, let us assume that each version of IRP Manager can only 
communicate adequately with the corresponding version of IRP Agent (and vice- 
versa) in the absence of the NBI Version Mediator 21. FIG. 3 shows how, in this 

1 5 case, communication is performed directly between each IRP Manager and its 
corresponding same version IRP Agent (i.e. IRP Manager 23 directly with IRP 
Agent 26, both version x; IRP Manager 24 directly with IRP Agent 27, both 
version x-1; and IRP manager 25 directly with IRP Agent 28, both version x+1). 
FIG. 3 further schematically shows the NBI Version Mediator 21 facilitating 

20 communication between each IRP Manager and IRP Agent (and vice-versa) 
which in combination is of different respective versions (i.e. communication 
between IRP Manager 23 being version x and each of IRP Agent 27 being version 
x-1 and IRP Agent 28 being version x+1; communication between IRP Manager 
24 being version x-1 and each of IRP Agent 26 being version x and IRP Agent 28 

25 being version x+1; and communication between IRP Manager 25 being version 
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x+1 and each of IRP Agent 26 being version x and IRP Agent 27 being version x- 
1). 

An overview of the operation of the NBI Version Mediator 21 will now be 
5 described. As defined in the 3GPP Technical Specification (e.g. CORBA reference 
3GPP 32. xxx series of specifications, where CORBA is Common Object Resource 
Broker Architecture), the NBI in effect has an NBI bus. The NBI Version Mediator 
21 sits on the NBI bus and exposes itself as instances of both pseudo IRP 
Managers and pseudo IRP Agents capable of supporting all (or at least a useful 

10 number of) versions of the NBI, IRPs & NRMs (see 3GPP 32.xxx series of 
specifications) required to be supported across a network. The NBI Version 
Mediator exposes itself on the interface when an IRP Manager instance and an 
IRP Agent instance need to communicate and can only support incompatible 
versions of NBI. In these cases the NBI Version Mediator 21 intervenes between 

1 5 the IRP Manager and IRP Agent, so that the IRP Agent sees the IRP Manager as 
its own version and the IRP Manager sees the IRP Agent as its own version. 
Software in and/or forming part of the NBI Version Mediator 21 is responsible 
for resolving the incompatibilities across the two version of the interface when 
there are differences and it is required to support forward and backward 

20 incompatibilities in the network over the NBI. For example, the following may be 
mediated:- 

1) Behaviour 

2) New/changed Operations 

3) New/changed Operations parameters 

25 4) New/changed Managed Object Classes (MOC) 
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5) New/changed MOC attributes. 

In conventional arrangements, The IRP Manager is responsible for 
discovering which instances of IRP Agent support its requirements for managing 
5 the network (Versions for IRPs (operations etc), NRMs (MOCs etc), NE 
instances). Generally, The IRP Managers first make a broadcast or similar 
method (e.g. search) to discover all the real IRP Agent instances in a network and 
identify the details of what NBI they can support. The IRP Manager collate the 
responses so that subsequently all associated NBI management operations across 
10 the NBI can be directed by the IRP Manager to an appropriate IRP Agent 
instance capable of supporting the scope of the operations (scope includes 
Versions for IRPs (operations etc), NRMs (MOCs etc), NE instances) the IRP 
Manager requires to be supported and that it is compatible with. 

15 In this embodiment, in similar fashion to an IRP Manager, the NBI Version 

Mediator 21 performs a similar broadcast to discover all the real IRP Agents, 
identify what they can support, and collate the responses. 

Preferably, following the first broadcast for discovery, the IRP Manager 
20 secondly, if required, explicitly requests the NBI Version Mediator 21 as an 
Agent if it can support specific scopes that could not be discovered as being 
supported by the real IRP Agents in the network . 

In other words, firstly the IRP Manager requests the "rear 7 IRP Agents, i.e. 
25 sends an appropriate request message, enquiring they can support. After this, the 
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IRP Manager communicates with the NBI Version Mediator 21 in the same (or 
similar) way as if it were any "real" IRP Agent, to explicitly request and 
determine what it can support that is not already supported by other "real" IRP 
Agents. For example, on the first request the IRP Agent may respond to say it 
5 supports R99 and R5 (e.g. specific releases of standards), but none respond that 
they support R4. On the second request the IRP Manager requests the NBI 
Version Mediator 21 as to what it can support. When the NBI Version Mediator 
responds R4, this is registered by the IRP Manager. 

10 The NBI Version Mediator 21 then compares these requests with what the 

IRP Agents have indicated they could support, and against its available 
repertoire of conversions between NBI versions, to see if it can match and 
support mediation. The NBI Version Mediator 21 may also more explicitly try to 
rediscover further scope if this was not initially found on the first broadcast for 

15 discovery or fully confirmed to the level of detailed required. Where matches are 
confirmed and the NBI Version Mediator 21 is capable of resolving forward or 
backward compatibility using its mediation repertoire, it will indicate this to the 
IRP Manager in the same or similar way an IRP Agent would in conventional 
operation. In overview, for the specific mediation identified as possible, the NBI 

20 Mediator will maintain sufficient information internally so that when the 

instance of the IRP Manager subsequently uses the NBI Mediator for the scope 
identified, the NBI Mediator can associate it with the appropriate mediation from 
its repertoire and the specific instance of IRP Agent it needs to mediate between. 
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FIG. 4 is schematic illustration of the NBI Version Mediator 21 in terms of 
functional modules thereof. The NBI Version Mediator 21 comprises an NBI bus 
interface 41, a controller 42, a Pseudo Agent 43, a Pseudo Manager 44, a rules 
engine 45, and a rules database 46. The controller 42 is functionally coupled to 
5 the Pseudo Agent 43, the Pseudo Manager 44, the rules engine 45 and the NBI 
bus interface 41. The NBI bus interface 41 is also functionally coupled to each of 
the Pseudo Agent 43 and the Pseudo Manager 44. The Pseudo Agent 43 and the 
Pseudo Manager 44 are also functionally coupled to each other. The Pseudo 
Manager 44 is also functionally coupled to the rules engine 45. The rules engine 

10 45 is also coupled to the rules database 46. An IRP Manager input 51 and an IRP 
Manager output 52 for communication with IRP Managers are provided for the 
NBI bus interface 41. An IRP Agent input 53 and an IRP Agent output 54 for 
communication with IRP Agents are also provided for the NBI bus interface 41. 
An operator (or user) interface 47, in this example a personal computer, is 

1 5 functionally coupled to the NBI Version Mediator 21, in this example to the rules 
database 46. 



The NBI bus interface 41 provides interface to, for example, Common 
Object Request Broker Architecture (CORBA) which allows integration of a wide 

20 variety of object systems i.e. in this case IRP Managers and IRP Agents in an 

NMC & NEM based management network. This will now be described in more 
detail with reference to FIG. 5. FIG. 5 is a schematic illustration representing a 
request 60 being sent by a client 61 to an object implementation 62. The client 61 
is the entity that wishes to perform an operation on the object and the object 

25 implementation 62 is the code and data that actually implements the object i.e. 
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IRP Manager and IRP Agent respectively. An Object Response Broker (ORB) 63 is 
responsible for the mechanisms required to find the object implementation 62 for 
the request 60, to prepare the object implementation 62 to receive the request 60, 
and to communicate the data making up the request 60. The interface the client 
5 sees is completely independent of where the object is located, what programming 
language it is implemented in, or any other aspect which is not reflected in the 
object's interface. 

The controller 42 is responsible for overall control of the various modules 
10 of the NBI Version Mediator 21, and controls scheduling, maintaining threads 
and directing internal and external messages to appropriate modules and 
instantiations. The controller 42 maintains a record of concurrent processing and 
earlier records of negotiated supported mediations between IRP Managers and 
IRP Agents instances, within the domains of MOs, Versions, Operations and 
15 Notifications. 



The Pseudo Agent 43 implements behaviour that emulates the regular IRP 
Agent for firstly responding to the IRP Managers with versions and scope 
supported for mediation, and secondly responding to operations and sending 
20 notifications for the versions of the interface being mediated. 



The Pseudo Manager 44 implements behaviour that emulates the regular 
IRP Manager for interacting with other IRP Agents in the network to firstly get 
versions and scope supported by other IRP Agents, and secondly send 
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operations and receiving notifications to/from IRP Agents versions being 
mediated. 

The rules engine 45 is responsible for providing, to the Pseudo Manager 
44 and the Pseudo Agent 43, translations between incoming event and outgoing 
translated event, for all operation and notifications supported and between all 
versions mediated. 

The rules database 46 holds a database of a predefined and/or updateable 
set of rules for translations to be performed by the rules engine 45. The rules 
engine identifies the valid scope of operations, mediated versions and Managed 
Objects (MO) supported by the NBI Version Mediator 21. 

The operator interface 47 is provided to allow the rules database 46 and 
the rules engine 45 to be updated. The operator interface can also allow rules to 
be activated and deactivated in real time. 

Each of the functional modules described above, and indeed the NBI 
Version Mediator 21 as a whole, may be implemented by configuring or adapting 
any suitable apparatus, for example a computer or other processing apparatus, 
forming all or part of one or more of the management parts of a communications 
system or network, or by providing new apparatus such as a computer or other 
processing apparatus. In all these cases, the apparatus may be in the form of 
hardware, firmware, or software, or any combination of these. The apparatus 
may comprise one or more processors, for implementing instructions and using 
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data stored in a storage medium such as a computer memory, hard disk, floppy 
disk, ROM, PROM etc. The processor may be a computer, a network of 
computers, or one or more dedicated processors, either collocated or distributed 
geographically. 

5 

A further aspect useful for understanding the present invention will now 
be described with reference to FIG. 6. FIG. 6 is a schematic illustration of a 
managed object containment tree, with IRP Agents scope superimposed over 
them. In FIG. 6, black squares represent managed objects, labelled here for 

10 example MO-1 to MO-15. Managed objects are a software object well understood 
by the skilled person. Lines connecting two managed objects represent 
containment. In this example, MO-1 may for example represent a managed 
object for a national cellular communication network operator's network, for 
example Vodafone (RTM). MO-2 may for example represent a managed object 

15 for vendor A's managed elements. MO-5 may for example represent a managed 
object for an RNC. MO-6 may for example represent a managed object for a 
Node-B. MO-10 may for example represent a managed object for a cell. In this 
example, the scope of IRP Agent 26 encompasses MO-2, MO-5, MO-6, MO-9 and 
MO-10; the scope of IRP Agent 27 encompasses MO-3, MO-7, MO-11, MO-14, 

20 MO-1 2 and MO-15; and the scope of IRP Agent 28 encompasses MO-4, MO-8 and 
MO-13. 

FIGs. 7, 8 and 9 are call sequence flowcharts showing process steps 
employed in an embodiment of the present invention. FIG. 7 shows the overall 



-17- 



process steps at a network level; FIGs. 8 and 9 show process steps performed 
internally by the NBI Version Mediator during the overall process of FIG. 7. 

The process shown in FIG. 7 is in two main stages. The first is 
5 initialisation, i.e. an initial "Get Versions" stage; the second is operations, i.e. 

general operation and notifications. At start up the Get Version is first run before 
operations and notifications can be mediated. (FIG. 8 shows internal steps during 
the initialisation stage of FIG. 7; FIG. 9 shows internal steps during the operations 
stage of FIG. 7). 

10 

In the general process of finding compatibility between IRP Manager 
instances and IRP Agent instances to be described with reference to FIGs. 7 to 9, 
it will be assumed that an IRP Manager initiates the process by searching for IRP 
Agents that: 

15 • can support its requirements within the scope versions it can support, 

• can support the scope of MOs (as in FIG. 6 for example) it requires to 
manage 

• can support the operations and notification it wishes to apply to them. 

20 Referring firstly to FIG. 7, at step s20 the IRP Manager 23 sends a get 

request to the IRP Agent 26 requesting whether the IRP Agent 26 supports 
version x (Vx) of the NBI. At step s40, the IRP Agent 26 responds to the IRP 
Manager 23 confirming that it does support version x. Optionally, at the same 
time as step s20 or as separate steps the IRP Manager 23 may request the scope of 

25 which MOs the IRP Agent 26 can support. In this case the IRP Agent 26 also 
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responds to this request, e.g. according to the example scenario shown in FIG. 6 
the IRP Agent 26 responds indicating it can support MOs 2, 5, 6, 9 and 10. (Steps 
s20 and s40 are as performed in conventional arrangements, and are included for 
comparison purposes.) 

5 

In this example the same process(es) is (are) repeated for IRP Agent 27. At 
step s60, the IRP Manager 23 sends a get request to the IRP Agent 27 requesting 
whether the IRP Agent 27 supports version x (V*) of the NBI. In the case of the 
IRP Agent 27 it does not support version x, it instead supports version x-1. 
10 Hence, at step s80, the IRP Agent 27 responds to the IRP Manager 23 with a 

message informing the IRP Manager 23 that the IRP Agent 27 does not support 
version x. Optionally, the IRP Agent 27 may also respond with an indication of 
which alternate versions it does support. 

15 After receiving the IRP Agent 27' s response that it does not support 

version x (or, if the IRP Manager 23 had also requested the MO scope, then after 
receiving the IRP Agent 27' s response that it does not support version x and/or 
the requested MO scope), at step si 00, the IRP Manager 23 sends the same 
request to the NBI Version Mediator 21, to determine whether it can support 

20 version x , and whether it can cover the required scope of MOs, i.e. the MOs of 
the IRP Agent 27, i.e. MOs 7, 11, 12, 14 and 15 as shown in FIG. 6). 
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Then the NBI Version Mediator 21 processes the get request and 
determines that it can potentially facilitate the IRP Manager 23 , s version x 
request by mediating between version x and version x-1 (as will be described in 
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more detail below with reference to FIG. 8). Thus the NBI Version Mediator 21 
sends get requests to available IRP Agents to determine which ones support 
version x-1. For conciseness, only three such requests are described here, i.e. at 
step si 10 the NBI Version Mediator 21 sends a get request for version x-1 to the 
IRP Agent 28, at step si 20 the NBI Version Mediator 21 sends a get request for 
version x-1 to the IRP Agent 26, and at step sl30 the NBI Version Mediator 21 
sends a get request for version x-1 to the IRP Agent 27. (Note, steps si 10, sl20 
and si 30, and equivalent transmits to other IRP Agents, may be sent in the form 
of a broadcast transmission.) 

At step sl50, the IRP Agent 28 responds to the NBI Version Mediator 21 
that it does not support version x-1; likewise at step si 60, the IRP Agent 26 
responds to the NBI Version Mediator 21 that it does not support version x-1. 
Hence these responses from these IRP Agents are not processed further by the 
NBI Version Mediator. 

However, at step si 80, the IRP Agent 27 responds to the NBI Version 
Mediator 21 that it does support version x-1, and for the context of the requested 
scope of MOs. 

Thus the NBI Version Mediator 21 is aware that it will be able to facilitate 
the IRP Manager 23's version x request by mediating between version x and 
version x-1. Thus, at step s200, the NBI Version Mediator 21 responds to the IRP 
Manager 23 that it can support version x (and may further specify details of the 
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scope supported). Note it does not need to mention that the support will involve 
mediation through version x-1. 

Above described steps s20 to s200 represent the initialisation stage of the 
5 overall process. On successful completion of this, the overall process moves to 
the operations stage, as follows. 

At step s220, the IRP Manager 23 sends a message invoking an operation 
to the IRP Agent 26 under their shared version x and for an MO within the scope 
10 of the IRP Agent 26 (i.e. MO 2, 5, 6, 9 or 10 as shown in FIG. 6). The IRP Agent 26 
straightforwardly performs the operation and, at step s240, returns the 
appropriate response. (Steps s220 and s240 are as performed in conventional 
arrangements, and are included for comparison purposes.) 

1 5 We now consider the process when the IRP manager 23 wishes to invoke 

an operation under version x within the scope of the IRP Agent 27. As the 
outcome of the above described initialisation stage, the NBI Version Mediator 21 
is viewed by the IRP Manager 23 as the entry point for such an operation. 
Therefore, at step s260, the IRP Manager 23 sends a message invoking the 

20 required operation to the NBI Version Mediator 21. 

This is processed by the NBI Version Mediator 21 (as will be described in 
more detail below with reference to FIG. 9) to convert the received version x 
operation request into a version x-1 operation request and, at step s280, the NBI 



-21- 



Version Mediator 21 sends the corresponding version x-1 operation request 
message invoking the operation to the IRP Agent 27. 

The IRP Agent 27 performs the operation, and, at step s300, returns the 
5 appropriate response (under version x-1) to the NBI Version Mediator 21. 

The NBI Version Mediator processes the response (as will be described in 
more detail below with reference to FIG. 9) to convert (or translate) the version x- 
1 response to a version x response, and then, at step s320, sends the converted (or 

10 translated) response to the IRP Manager 23. Following an initial synchronous 
response there may follow additional subsequent associated asynchronous 
responses sent by the IRP Agent in the form of notifications. The NBI Version 
Mediator processes such notifications in a similar way Le. steps s300 and s320 are 
repeated. Since notifications are associated with IRP Agent detecting events and 

1 5 the notification being sent to all IRP Managers that subscribed to a type and 
scope of notification the mediation will done in the context of each IRP 
Manager's original subscription operation. 

Certain steps performed within the NBI Version Mediator 21 during the 
20 initialisation stage described above with respect to FIG. 7 will now be described 
with reference to FIG. 8. 

FIG. 8 shows the above described step slOO of the NBI Version Mediator 
21 receiving, from the IRP Manager 23, the get request under version x. More 
25 particularly, this is received by the NBI Bus Interface 41 module of the NBI 
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Version Mediator 21. A context and thread is then established and the Pseudo 
Agent 43 opened, so that from the perspective of the IRP Manager 23, the NBI 
Version Mediator 21 appears as a normal IRP Agent. In particular, at step slOl, 
the get request is forwarded from the NBI Bus Interface 41 to the controller 42, 
5 and, at step si 02, the get request is further forwarded from the controller 42 to 
the Pseudo Agent 43 which is thereby activated (or further activated if it has 
already been operating for other situations). 

The Pseudo Agent 43 initiates a process of establishing what mediation, 
10 for version x in the context of the requested scope, it may support, by invoking 
the Rules Engine 45 and the Rules Database 46. In particular, at step sl03, the 
Pseudo Agent 43 forwards a request support under version x message, and 
associated details, to the Rules Engine 45. 

1 5 The Rules Engine 45, interrogating the Rules Database 46 as required, 

determines that in the present case the NBI Version Mediator 21 can potentially 
support mediation between versions x and x-1 provided it can locate an IRP 
Agent in the network able to support version x-1 for the requested scope. The 
Rules Engine 45 then invokes the Pseudo Manager 44, i.e. at step sl04, the Rules 

20 Engine 45 sends, to the Pseudo Manager 44, a request support for version x-1 
message, to request some or all known IRP Agents in the network if they can 
support version x-1 for the required scope. 

The Pseudo Manager 44 now emulates an IRP Manager. In particular, the 
25 Pseudo Manager 44 formulates a get request under version x-1 for the required 
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scope, and at step sl05 forwards this get request to the controller 42. At step sl06, 
the controller 42 forwards this version x-1 get request to the NBI Bus Interface 41. 

The NBI Bus Interface 41 then sends this get request under version x-1 to 
5 relevant IRP Agents. In this particular example, this corresponds to steps si 10, 
sl20 and sl30 described above with reference to FIG. 7, i.e. at step si 10 the NBI 
Version Mediator 21 sends a get request for version x-1 to the IRP Agent 28, at 
step si 20 the NBI Version Mediator 21 sends a get request for version x-1 to the 
IRP Agent 26, and at step sl30 the NBI Version Mediator 21 sends a get request 
10 for version x-1 to the IRP Agent 27. 

For consistency with FIG. 7, FIG. 8 shows step sl50, where the NBI Bus 
Interface 41 receives, from the IRP Agent 28, the response that the IRP Agent 28 
does not support version x-1, and step sl60, where the NBI Bus Interface 41 
15 receives, from the IRP Agent 26, the response that the IRP Agent 26 does not 

support version x-1. These IRP Agent responses are not processed further by the 
NBI Version Mediator 21. 

In addition, at step sl80, the NBI Bus Interface 41 receives, from the IRP 
20 Agent 27, the response that the IRP Agent 27 does support version x-1 for the 
given scope. At step sl81, this response is forwarded to the controller 42, and 
further at step sl82 this response is forwarded to the Pseudo Manager 44. 

The Pseudo Manager 44 responds to the Rules Engine 45 that there is an 
25 IRP Agent that can support version x-1 for the given scope, i.e. at step sl83 the 
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Pseudo Manager 44 effectively forwards the response that IRP Agent supports 
version x-1 to the Rules Engine 45. 

The Rules Engine 45 processes this information, in part by interrogating 
5 the Rules Database 46. Then the Rules Engine 45 updates the controller 42 with 
the current valid supported mediation between the IRP Manager 23 and the IRP 
Agent 27 for future context and scheduling of communication of these specific 
entities i.e. at step sl84 the Rules Engine 45 sends updated support mediation 
information to the controller s42, indicating that mediation is supported between 
10 IRP Manager 23 and IRP Agent 27for the required scope. 

At step sl85, the Rules Engine 45 furthermore sends a response to the 
Pseudo Agent 43 indicating that mediation for version x is supported. The 
information may also include specifics of the actual scope supported, derived 
15 from the response received from the IRP Agent 27 and the Rules Database e.g. 
the MOs supported by the IRP Agent 27. 

At step si 86, the Pseudo Agent 43 effectively forwards this support 
version x message to the controller 42. At step sl87 the controller further 
20 forwards this message to the NBI Bus Interface 41. 

Then the NBI Bus Interface 41 performs the earlier described step s200 of 
the NBI Version Mediator 21 responding to the IRP Manager 23 that it can 
support version x (and may further specify details of the scope supported). 

25 
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Certain steps performed within the NBI Version Mediator 21 during the 
operations stage described above with respect to FIG. 7 will now be described 
with reference to FIG. 9. 



5 FIG. 9 shows the above described step s260 of the NBI Version Mediator 

21 receiving, from the IRP Manager 23, the message invoking the required 
operation under version x. More particularly, this is received by the NBI Bus 
Interface 41 module of the NBI Version Mediator 21. 



10 At step s261, this operation request is forwarded to the controller 42. At 

step s262, the controller 42 forwards the operation request to the Pseudo Agent 
43. 



The Pseudo Agent 43 will now emulate an IRP Agent from the perspective 
1 5 of the IRP Manager 23. The Pseudo Agent 43 does this as follows. At step s263, 
the Pseudo Agent 43 requests the Rules Engine 45 to convert the version x based 
operation and MOs to version x-1, apply and return the response. 



Based on the information supplied by the IRP Manager 23, the Rules 
20 Database, and information held by the controller after initialisation, the Rules 

Engine translates the operation request and MO from version x to version x-1 (as 
required for mediation between version x and version x-1). 
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Then, at step s264, the Rules Engine 45 sends a request to the Pseudo 
Manager 44 effectively requesting it to request the IRP Agent 27 to process the 
converted version X-l based operation. 

The Pseudo Manager formulates the operation request as a standard 
version x-l operation, and, at step s265, forwards this version x-l operation to the 
controller 42. At step s266 the controller forwards the operation to the NBI Bus 
Interface. At step s280, as described above with reference to FIG. 7, the NBI Bus 
Interface 41 sends the operation to the IRP Agent 27. 

The IRP Agent 27 receives the x-l operation, and applies the operation to 
its version x-l MOs. At step s300, as described above with reference to FIG. 7, the 
IRP Agent 27 returns a version x-l response for the operation to the NBI Bus 
Interface 41 of the NBI Version Mediator 21. 

At step s301, the NBI Bus Interface 41 forwards the response to the 
controller 42. At step s302, the controller 42 forwards the response to the Pseudo 
Manager 44. 

At step s303, the Pseudo Manager 44 and the Rules Engine 45 interact, and 
interrogate the Rules Database as 46 required, to convert (or translate) the x-l 
version of response to an x version response. 

At step s304, the Pseudo Manager 44 forwards the x version response to 
the Pseudo Agent 43. The Pseudo Agent 43 can now respond in the manner of a 
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standard IRP Agent to the operation request received by virtue of steps s260, 
s261 and s262. More particularly, at step s305, the Pseudo Agent 43 forwards the 
version x response to the controller 42. At step s306, the controller 42 forwards 
the version x response to the NBI Bus Interface 41. At step s320, as described 
above with reference to FIG. 7, the NBI Bus Interface 41 sends the version x 
response to the IRP Manager 23. This concludes this particular process of the 
operation for the MOs. 

Internally, notifications are processed in a similar way to the synchronous 
IRP Agent response handling shown in FIG. 9 i.e. steps s300 through s320 
inclusive in the context of the IRP Manager original subscription operation. 

It will be appreciated that the process steps described above, and the order 
in which they are performed, are by way of example only. In practice the process 
will vary according to the arrangement of IRP Managers, IRP Agents, networks, 
scopes required to be processed, and so on. Likewise, the process may vary 
according to ways in which the NBI Version Mediator, or corresponding 
apparatus, is implemented. For example, process steps will vary according to 
which functional modules form the NBI Version Mediator, and according to 
which way such modules interact. 

The above embodiments provide the potential for the following 
advantages, amongst others, to be obtained: 

• Avoidance or at least reduction the need to upgrade all network 
managers and network elements to a common version of the NBI. 
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• Support for legacy entities in an evolving network without the need 
to upgrade them. 

• The process and arrangement is transparent to extant IRP Managers 
and IRP Agents, 

5 • Prior art in this area means in general Reduces or removes the need 

for IRP Managers and IRP Agents to be able to support at least 1 common 
version of the interface without communication failing due to incompatible 
operation signatures at the NBI implementation level. 

• Common version mediation may be applied to operations, 
10 notifications and MOs. 

• May be applied to different vendors and/or ISVs. 

• May be employed as a temporary measure while differences of 
versions in a management layer of a network are updated or otherwise resolved. 
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CLAIMS 

1. A method of communicating between a telecommunications network 
management centre, NMC (10), and a telecommunications network element 
5 manager, NEM (4), over an interface (15) defined by a standard, the NMC (10) 
using one version of the standard, hereinafter called the first version of the 
standard, and the NEM (4) using a different version of the standard, hereinafter 
called the second version of the standard; the method comprising: 

one of the NMC (10) and the NEM (4) sending a request under the first 
1 0 version of the standard to a mediator (21); 

the mediator (21) converting the request under the first version of the 
standard to a corresponding request under the second version of the standard; 

the mediator (21) sending the corresponding request under the second 
version of the standard to the other of the NMC (10) and the NEM (4); 
1 5 the other of the NMC (10) and the NEM (4) sending a response under the 

second version of the standard to the mediator (21); 

the mediator (21) converting the response under the second version of the 
standard to a corresponding response under the first version of the standard; and 
the mediator (21) sending the corresponding response under the first 
20 version of the standard to the one of the NMC (10) and the NEM (4). 



2. A method of mediating communication between a telecommunications 
network management centre, NMC (10), and a telecommunications network 
element manager, NEM (4), over an interface (15) defined by a standard, the 
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NMC (10) using one version of the standard, and the NEM (4) using a different 
version of the standard; the method comprising: 

receiving a request under a first version of the standard from one of the 
NMC (10) and the NEM (4); 
5 converting the request under the first version of the standard to a 

corresponding request under a second version of the standard; 

sending the corresponding request under the second version of the 
standard to the other of the NMC (10) and the NEM (4); 

receiving a response under the second version of the standard from the 
10 other of the NMC (10) and the NEM (4); 

converting the response under the second version of the standard to a 
corresponding response under the first version of the standard; and 

sending the corresponding response under the first version of the 
standard to the one of the NMC (10) and the NEM (4). 

15 

3. A method according to claim 1, further comprising the mediator (21) 
determining a suitable NMC (10) or NEM (4) under the second version of the 
standard from among a plurality of NMC's or a plurality of NEM's. 

20 4. A method according to claim 2, further comprising determining a suitable 
NMC (10) or NEM (4) under the second version of the standard from among a 
plurality of NMCs or a plurality of NEM's. 

5. A method according to any of claims 1 to 4, wherein the request under the 
25 first version of the standard is from an Integration Reference Point manager of 
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the one of the NMC (10) and the NEM (4), and the response under the second 
version of the standard is from an Integration Reference Point agent of the other 
of the NMC (10) and the NEM (4). 

5 6. A method according to claim 5, wherein the mediator (21) emulates an 
Integration Reference Point manager and an Integration Reference Point agent. 

7. A method according to any of claims 1 to 6, wherein the request under the 
first version of the standard is one of the following group: 

10 (i) a get request; 

(ii) a request to perform an operation; and 

(iii) a notification. 

8. A method according to any of claims 1 to 7, wherein the standard is a 3rd 
1 5 Generation Partnership Project Universal Mobile Telecommunications System 

(UMTS) Management standard, and the interface is the north bound interface, 
NBI. 



20 



9. A storage medium storing processor-implementable instructions for 
controlling a processor to carry out the method of any of claims 1 to 8. 
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10. Apparatus for mediating communication between a telecommunications 
network management centre, NMC (10), and a telecommunications network 
element manager, NEM (4), over an interface defined by a standard, the NMC 
(10) using one version of the standard, and the NEM (4) using a different version 
of the standard; the apparatus comprising: 

means for receiving a request under a first version of the standard from 
one of the NMC (10) and the NEM (4); 

means for converting the request under the first version of the standard to 
a corresponding request under a second version of the standard; 

means for sending the corresponding request under the second version of 
the standard to the other of the NMC (10) and the NEM (4); 

means for receiving a response under the second version of the standard 
from the other of the NMC (10) and the NEM (4); 

means for converting the response under the second version of the 
standard to a corresponding response under the first version of the standard; and 

means for sending the corresponding response under the first version of 
the standard to the one of the NMC (10) and the NEM (4). 

11. Apparatus according to claim 10, further comprising means for 
determining a suitable NMC (10) or NEM (4) under the second version of the 
standard from among a plurality of NMC's or a plurality of NEM's. 
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12. Apparatus according to claim 10 or 11, wherein the request under the first 
version of the standard is from an Integration Reference Point manager of the 
one of the NMC (10) and the NEM (4), and the response under the second 
version of the standard is from an Integration Reference Point agent of the other 

5 of the NMC (10) and the NEM (4). 

13. Apparatus according to claim \% adapted to emulate an Integration 
Reference Point manager and an Integration Reference Point agent. 

10 14. Apparatus according to any of claims 10 to 13, wherein the request under 
the first version of the standard is one of the following group: 

(i) a get request; 

(ii) a request to perform an operation; and 

(iii) a notification. 

15 

15. Apparatus according to any of claims 10 to 14, wherein the standard is a 
3rd Generation Partnership Project Universal Mobile Telecommunications 
System (UMTS) Management standard, and the interface is the north bound 
interface, NBI. 

20 

16. A method of communicating between a network management centre and 
a network element manager substantially as hereinbefore described with 
reference to the accompanying drawings. 
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17. Apparatus for mediating communication between a network management 
centre and a network element manager substantially as hereinbefore described 
with reference to the accompanying drawings. 




- Ftitenl 
% Office I 



'''I . i ft s 



Application No: 
Claims searched: 



GB 0300652.5 
1 to 17 



Examiner: 
Date of search: 



INVESTOR IN PEOPLE 



Daniel Voisey 
14 May 2003 



Patents Act 1977 : Search Report under Section 17 
Documents considered to be relevant: 



Category 


Relevant 
to claims 


Identity of document and passage or figure of particular relevance 


X 
X 


1,2, 8 to 
10 and 15 

1,2, 8 to 
10 and 15 


EP 1050994 A2 (ALCATEL) see particularly paragraphs [0001] and 
[0003] and figure 1. 

GB 2301754 A (DSC) see particularly page 1 line 5 to page 2 line 1 . 



Categories: 



X 


Document indicating lack of novelty or inventive step 


A 


Document indicating technological background and/or state of the ait 


Y 


Document indicating lack of inventive step if combined 
with one or more other documents of same category 


P 


Document published on or after the declared priority date but before the 
filing date of this invention 


& 


Member of the same patent family 


E 


Patent document published on or after, but with priority date earlier 
than, the filing date of this application 



Field of Search: 

Search of GB, EP, WO & US patent documents classified in the following areas of the UKC V : 



H4K, H4L 



Worldwide search of patent documents classified in the following areas of the IPC 7 : 



H04L, H04Q 



The following online and other databases have been used in the preparation of this search report: 
WPI, EPODOC, JAPIO 



An Execuli vc Agency of the Department of Trade and Industry 



